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What is it? 


During the development of programs written in BASIC, it 
occasionally becomes desirable to renumber the lines of the 
program. This may be because the programmer finds the need 
to insert additional program lines, or simply to clean up 
the program so that the line numbers provide a more effect¬ 
ive indication of the relative position of lines within the 
program. 


Other BASIC renumbering programs have been offered to users 
of the Atari Personal Computer System, but have suffered 
from several failings or weaknesses. Routines have been 
published which renumber the lines, but not the references 
to the lines (GOTO's, GOSUB's, TRAP'S, etc.) - a virtually 
pointless exercise. Other renumbering programs will do 
this, but require the availability of an Atari 810 Disk 
Drive, a significant economic consideration. In addition, 
these renumbering utilities fail to recognize the use of 
variables and arithmetic expressions as line number refer¬ 
ences. 


BURP has none of these drawbacks. It offers a renumbering 
capability to those who must be content with an Atari 410 
Program Recorder, although it additionally offers improved 
performance to owners of an Atari 810 Disk Drive. BURP is 
indifferent to the presence of cassettes or diskettes be¬ 
cause it operates entirely in RAM. BURP renumbers refer¬ 
ences to lines as well as the lines themselves. It does not 
ignore the possibility and implications of variables and 
arithmetic expressions used as line number references. 
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How does it work? 


You have a program resident in RAM, which you have typed in, 
LOADed, or ENTERed. You merge the renumbering routine with 
your program by ENTERing BURP. 

You then execute the routine by keying in a direct mode GOTO 
to the BURP routine. 

BURP queries you for the new starting line number and the 
value of the line numbering increment you wish to use. 

BURP then proceeds to scan your tokenized RAM-resident BASIC 
program, line by line, looking for any references to line 
numbers. Any line numbers referred to are entered into a 
table, together with the RAM location of the reference. 

On completion of this process, a second scan of your token¬ 
ized program is made, renumbering the lines. As each line 
is given a new number, the old number is looked up in the 
table. If it appears there, the new line number is POKEd 
into the corresponding RAM address of the referencing 
statement. 


What are BURP's limitations? 


There are essentially three limitations. The first is a 
"logical" limitation, for which there is literally no solu¬ 
tion. If you write a program in such a way that references 
to line numbers are developed as the program is RUN, it is 
not possible to determine, by looking at a reference in the 
form of a variable or arithmetic expression, what it's value 
will be when the program is RUN. The author of BURP is of 
the opinion that the use of this technique is not a partic¬ 
ularly good programming practice. Of course, you might say 
"well, sure... because he can't handle it!". Not so! If you 
have ever tried to decipher or debug a program which was 
written using this technique, you will understand and 
appreciate this opinion. However, the author has made pro¬ 
vision for this practice. 
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Rather than make no attempt to accommodate variables and 
arithmetic expressions used as line number references, BURP 
was written to handle them in the same manner as the 
RESequence function of the best BASIC interpreters available 
on commercial time-sharing systems. 


If you follow a simple rule in formatting arithmetic ex¬ 
pressions as line number references, BURP will handle them 
properly: 

If the first element of the arithmetic 
expression is a numeric constant, the renum¬ 
bering utility will treat that element as a 
line number, and attempt to renumber it. 


For example, BURP will properly handle the following state¬ 
ments, assuming that 230 is a valid line number: 

150 GOTO 230+A 
160 GOSUB 230+(X*2) 

170 IF R=S THEN GOTO 230/P 


On the other hand, the following statements are some examp¬ 
les of references that cannot be renumbered: 

100 GOTO A 
110 GOTO X+Y 
120 GOSUB W+230 


However, in the case of lines 100 through 120 above, BURP 
will pause to warn you of the existence of these references, 
and give you the opportunity to cancel the renumbering pro¬ 
cess. You can then study your program to insure that not 
renumbering the reference is all right, or else modify the 
statement in question so that it can be properly handled. 

For further information, read the "Troubleshooting and 
Cautions" section. 
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The second limitation of BURP is a "physical" one. The same 
thing that gives BURP its performance advantage may, in some 
cases, constitute a limitation. Because it co-exists in RAM 
with your BASIC program, it operates at RAM speeds. How¬ 
ever, this means that you must have enough RAM to contain 
(a) your BASIC program, (b) BURP, and Cc) a dimensioned 
array sufficient to contain an entry for each line number 
reference. 


The third limitation is a relatively minor one. Because the 
renumbering routine is itseif a BASIC program, it must use 
some line numbers. Obviously, the line numbers used by your 
program cannot duplicate those used by BURP. The BURP rou¬ 
tine is distributed with line numbers in the range of 32500 
through 32761. Consequently, your program cannot use a line 
number higher than 32499. If, in the process of renumbering 
your program, a new line number is developed which would 
violate this rule, BURP will terminate, advising you of the 
potential conflict. You can then begin the renumbering 
process again, perhaps using a different increment or lower 
starting line number value. 


What are the minimum machine requirements of BURP? 


The condensed, or "mashed" version of BURP occupies 3300 
bytes of RAM. The remainder of the RAM requirement depends 
on the size of the program you wish to renumber, and the 
number of line references within it. Since the Atari Oper¬ 
ating System itself will occupy 3058 bytes of your available 
RAM space, and 3058 + 3300 = 6358, the realistic minimum 

equipment requirement would be: 

an Atari 400/800 with 16K RAM 
an Atari BASIC Language Cartridge 
an Atari 410 Program Recorder 

Of course, either an Atari 410 Program Recorder or Atari 810 
Disk Drive can be used for the process of LOADing, SAVEing, 
and ENTERing programs. 
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While it would be nice if BURP could operate in less RAM 
(some suggestions for further condensing it are provided in 
the Advanced Technical Information section), you shouldn't 
get excited over giving up 3300 bytes. Many programs to be 
renumbered will have this much additional RAM available for 
graphics workspace and arrays, which will be unoccupied un¬ 
til the program is actually RUN. To put things in perspec¬ 
tive, DOS II grabs 5579 bytes, in addition to the 3058 
occupied by the Operating System. Therefore, in a .pinch, 
DOS II users could run BURP in cassette mode, with their 
diskette(s) temporarily detached. 


Are any "tricks" used? 

One of the author's objectives, aside from satisfying his 
own requirement for a renumbering utility, was to meet the 
challenge of performing this task without resorting to 
functions which would not be available to the average per¬ 
son. Although, using Assembler Language, much higher 
performance could have been achieved, BURP was written en¬ 
tirely in BASIC, without so much as a POKE at machine 
language and the USR function. As such, it provides not 
only a useful tool, but an interesting example of the flex¬ 
ibility of Atari BASIC. 



II. GETTING STARTED 
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Available on both cassette and diskette, BURP is written in 
LIST (untokenized) form. The tape contains only the 
"mashed" version. The diskette contains a mashed version 
and an unmashed version. The unmashed version of BURP is 
provided primarily for your perusal of the program. The 
mashed version is the one that you will actually use. See 
Section VI of this manual for a listing of the unmashed 
program. 

On receiving any piece of software, the first thing you want 
to do is protect yourself against coffee spills, cigarette 
ashes, and the variety of jeopardies that hover about your 
"data center". Make a backup copy. For cassette, the 
procedure is as follows: 

With your Atari BASIC cartridge inserted in 
the left cartridge slot, turn your computer 
on. 


Insert the BURP cassette in your Atari 410 
Program Recorder in position to read Side 1. 

Press REWIND, to insure that you are at the 
beginning of the tape, then press PLAY. 

Type NEW and press RETURN once. This will 
ensure that RAM is free of any other program 
code. 

Type ENTER "C:" and press RETURN twice. This 
will read the BURP program into RAM. 

Insert a fresh cassette in your Atari 410 
Program Recorder. 

Press REWIND, to insure that you are at the 
beginning of the tape. Then, press RECORD and 
PLAY, to put the unit into "record" mode. 

Type LIST "C:" and press RETURN twice. The 
BURP program will then be LISTed on your 
cassette in untokenized form. 

For diskette, use DOS II menu selection C (if you have more 
than one disk drive) or 0 (if you have only one disk drive) 
to duplicate the files. The file names are BURP (mashed 
version) and BURP.REM (unmashed version). If you transfer 
the cassette program to diskette, be sure to store it on 
diskette in LIST format (e.g., LIST "D:BURP") so that you 
can ENTER it into RAM that is already occupied by the pro¬ 
gram to be renumbered. 



III. USING BURP 


With an Atari 410 Program Recorder 


Place your BASIC program in RAM, by typing it 
in, LOADing or CLOADing it, or ENTERing it. 

If you have typed it in, or made modifications 
to it, CSAVE, SAVE, or LIST it to protect it 
from loss should a problem be encountered in 
renumbering it. 

If possible, RUN your program, to satisfy 
yourself that it is functioning properly prior 
to renumbering it. 

Press SYSTEM RESET. This will ensure that you 
haven’t left any non-standard values POKEd 
into the Operating System that might inter¬ 
fere with the successful execution of BURP. 

Type CLR and press RETURN once. This will 
insure that, if your program has DIMensioned 
any arrays, that space will be released and 
thus be available for use by BURP. 

Insert your BURP cassette in the Atari 410 
Program Recorder, positioned to read Side 1. 

Press REWIND to insure that you are at the 
beginning of the tape, then press PLAY to put 
the recorder in "read" mode. 

Type ENTER "C:" and press RETURN twice. This 
will read BURP into RAM, co-resident with your 
BASIC program to be renumbered. 

Type GOTO 32500 and press RETURN. This will 
begin execution of BURP. 

BURP will now clear the screen and display: 

New start line number?_ 

Respond with a numeric value indicating the 
line number that you would like your renum¬ 
bered program to begin with, then press 
RETURN. 



Using BURP 

With an Atari 410 Program Recorder 
(Continued....) 


BURP will then query you: 

Increment ?_ 

Respond with a numeric value indicating the 
line number increment you would like to use, 
then press RETURN. 

BURP will now commence scanning your BASIC 
program, line by line. As it does so, it will 
display: 


Scanning line: nnnn 

The number nnnn will give you an indication 
of the progress which BURP is making through 
your program lines. 

If, during this phase, BURP encounters a line 
number reference in the form of a variable 
name, it will display the line of your program 
containing that reference, "honk" at you, and 
ask you if you would like to continue. For 
example: 

350 IF A=B THEN GOTO XYZ 
Variable reference. 

Go ahead anyhow?_ 

If, upon examination of the line in question, 
you decide that it poses no problem that you 
can't cope with, respond with a "Y" followed 
by pressing RETURN. BURP will then ignore the 
reference, erase the line display from the 
screen, and continue to scan your program. 

On the other hand, if you aren't sure what the 
consequences of ignoring the variable refer¬ 
ence will be, respond with an "N" followed by 
pressing RETURN. BURP will then terminate, 
leaving your BASIC program untouched. Note 
that for safety's sake, any response other 
than "Y" will be considered equivalent to "N". 



Using BURP 

With an Atari 410 Program Recorder 
(Continued.) 


During this scanning phase, BURP is doing a 
preliminary calculation of what the new line 
numbers are going to be. If it determines 
that renumbering your program will result in 
a line number greater than 32499, it will 
display: 

New line number exceeds the 

maximum allowable value. 

There are no options when this occurs, and 
BURP will terminate its processing. You 
should then begin again, using a lower start¬ 
ing line number or smaller increment value. 

It is during this phase that BURP is entering 
line number references in an array that is 
limited by the RAM space available. If it 
encounters more line number references than 
can be handled in the available space, it will 
display: 


Insufficient RAM to handle 
more than nn references. 

BURP will terminate its processing. If you 
can either make more RAM available or reduce 
the number of line number references within 
your program, you may then begin again. 

Once BURP has completed its scan of your BASIC 
program, it will sort the line number refer¬ 
ences to facilitate their rapid identification 
during the actual renumbering phase. When the 
sort phase has been entered, BURP will 
display: 


Sorting the references: nnnn * 

As the sort progresses, the value nnnn will 
indicate an increasing count of the number of 
line number references which were detected. 
The asterisk will flash, indicating that 
sorting is taking place and reassuring you 
that, when a delay occurs, processing is in 
fact proceeding 
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Using BURP 

With an Atari 410 Program Recorder 
(Continued.) 


Upon completion of the sort phase, BURP will 
display: 


Renumbering bnnn as annn 

The two values bnnn and annn will indicate the 
before and after line numbers, respectively. 
Once this display appears, BURP has commenced 
the actual renumbering process and any pre¬ 
mature termination of BURP will leave you with 
a damaged program, as it will be only partly 
renumbered. 

Upon successful completion, BURP will generate 
a tone signal, READY will appear on the 
screen, and the cursor will be restored. 

At this point your BASIC program should be 
visible in RAM with the new line numbers 
applied. You may want to RUN it, to make 
certain that any variable line number refer¬ 
ences haven't caused a problem. 

The final step is to make a copy of your re¬ 
numbered program. Insert a fresh cassette in 
your Atari 410 Program Recorder. 

Press REWIND, then press RECORD and PLAY, to 
place the recorder in "record" mode. 

Type LIST "C:",0,32499 and then press RETURN 
twice. Your renumbered BASIC program will 
then be LISTed on the cassette. LISTing your 
program this way is necessary to strip it of 
the BURP program, which would otherwise be 
tacked on the end of it. If you don't mind 
this (you may want to keep BURP appended to a 
program that is under development), you can 
just as well CSAVE all of RAM or do a LIST 
"C:" without limiting it to the range 0 
through 32499. 
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BURP from an Atari 810 Disk Drive 
as that for the cassette unit. 


The procedure for using 
is essentially the same 


The principal difference is 
commands would be replaced as 


LIST "C:" 

use 

LIST "C:",0,32499 

use 

CLOAD 

use 

LOAD "C:" 

use 

ENTER "C:" 

use 


that any of the following 
follows: 

LIST "Dn:filnam.ext” 

LIST "Dn:filnam.ext",0,32499 
LOAD "Dn:filnam.ext" 

LOAD "Dn:filnam.ext" 

ENTER "Dn:filnam.ext" 


The file name of the mashed version is BURP; the file 
name of the unmashed version is BURP.REM. 


If you have an Atari 810 Disk Drive, using BURP will be 
much more pleasant since the operations required to ENTER 
it into RAM and LIST your renumbered program back onto 
diskette will be much quicker. 


However, as noted elsewhere, if you find that you need 
more RAM space to successfully renumber a program, detach 
your Atari 810 Disk Drive(s) and reinitialize your system 
to run without the Disk Operating System resident in RAM. 



IV. TROUBLESHOOTING AND CAUTIONS 
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There isn’t much potential for disaster using BURP, pro¬ 
viding you take some of the basic precautions that you 
would observe any time you were working on a program. 

Because BURP operates in RAM, it doesn't touch the previ¬ 
ous version of your program. Therefore, even if you make 
a mess of it by BREAKing into BURP while it's in the final 
renumbering phase, you still have your virgin copy out on 
tape or diskette. However, just to be nice, once BURP has 
displayed the message "Renumber nnnn as nnnn" on the 
screen, please don't interrupt it. If you do, you will 
have BASIC statements in RAM, some of which have been re¬ 
numbered and others which haven't. 

In the introduction, I discussed the use of variables as 
line number references. This is acceptable, but it's up 
to you to ensure that the line numbers which are derived 
from those variables when you RUN your program are the 
right ones. For example, you might have a sequence like 
this: 


150 LET X=TRNSTYPE 
160 GOTO 200+X 

Now, you may have written your program on the assumption 
that X will always have a value of 1, 2, or 3. There may 
not actually be a line 200, but you do have lines 201, 

202, and 203. One thing that BURP, or any other utility, 
can't do, is to renumber a reference to a nonexistent line 
number. Therefore, if you run these BASIC statements 
through BURP, you're going to have to handle the change 
to line 160 by yourself. 

If line 200 does in fact exist, BURP will properly renum¬ 
ber the reference to it in line 160. However, there's 
another problem that you've got to look out for. You've 
written this GOTO 200+X on the assumption that the arith¬ 
metic expression 200+X will yield the result 201, 202, or 

203. If you now renumber your program using an increment 
value other than 1, you've got a problem. Although the 
renumbering may result in one or two of these values (201, 
202, or 203) being a valid line number, unless you use an 
increment of 1, at least one of them will not exist. 
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(Continued.) 


One final caution: I haven't checked this out, but I see 
the possibility of a problem if you have really filled a 
logical line to its maximum, and increase the size of that 
line's number by one or more digit positions. 

For example, if line number 10 contains the maximum number 
of characters allowed on a logical BASIC line and, as the 
result of renumbering, it becomes line 100, you may have 
a problem. 

I think that as long as your program remains in tokenized 
form, either in RAM or SAVEd on cassette or diskette, it 
will RUN without objection. If you LIST your program on 
cassette or diskette, the correct un-tokenized statements 
will likely be written to the device. However, you might 
have a problem when you subsequently attempt to ENTER that 
LISTed program into RAM. Why? Because, in the example 
above, increasing the length, in digits, of the line num¬ 
ber may have shoved the last characters of your BASIC line 
beyond the maximum allowable logical line length. When 
BASIC is reading your ENTERed statements, it may object 
to this. 
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Two versions of BURP are on the diskette and one is on 
the cassette. One version is condensed ("mashed") to 

achieve maximum performance and minimum RAM space 
requirement. This version should be considered your 

operational version. It's on both diskette and cassette. 

The second version on the diskette is uncondensed, con¬ 
taining REMarks. It is intended to provide you with a 
readable program that you can follow with a minimum of 
difficulty, to satisfy your curiosity about how the pro¬ 
gram works. While reading the following description of 

the functions performed by various sections of the pro¬ 
gram, refer to the uncondensed version of BURP to see the 
corresponding BASIC statements. You can either display 
these lines on your screen (if you have the program on 

diskette and entered into RAM) or look over the program 
listing in Section VI. 


Program Narrative 


Lines 32500 - 32518: 

Before BURP begins executing, it issues a CLR statement 
to insure that all free RAM is made available. It then 
clears the screen, and requests the new starting line 
number and the increment you wish to use. Note that if a 
typing error is made in INPUTting either of these values, 
the error will TRAP to a re-prompt for both of these var¬ 
iables . 

Lines 32513 - 32525: 

Poking a "1" into location 752 suppresses display of the 
cursor. Then BURP DIMensions TL (an array used in token- 
izing line numbers) and Y0RN$ (a string variable used to 
accept responses). 

Lines 32526 - 32535: 

Initializes MAXTST (used to insure that new line numbers 
do not exceed 32499) equal to the new starting line number 
(NEWNR). BURP then calculates the capacity (CAP) of the 
line number/reference address table, using all available 
free RAM. The two arrays (OLDNR and RAMADD) comprising 
the table are then DIMensioned by CAP. 



Program Narrative 
(Continued....) 
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Lines 32536 - 32542: 

Sets the screen position to display the current line numbers 
as the corresponding BASIC lines are scanned. Obtains the 
beginning RAM address (P) of the BASIC program by PEEKing 
at locations 136 and 137. 

Lines 32543 - 32544: 

Gets the line number (LNMBR) of the current line by PEEKing 
at the first two bytes of the line. Then gets the length 
of the line (LNTH) by PEEKing at the third byte. 

Lines 32545 - 32547: 

When line number (LNMBR) 32500 is reached, terminate the 
scanning of the BASIC program and GOTO the next step, sort¬ 
ing the references and POKEing the new line numbers into 
RAM. 


Lines 32548 - 32555: 

Increment the maximum line number control variable (MAXTST) 
by the increment value (INCREMENT). If it exceeds 32499, 
notify the operator that the maximum allowable line number 
has been reached, and terminate the program. 

Lines 32556 - 32560: 

Set the screen position and display the number of the BASIC 
line that is currently being scanned. Execute the subrou¬ 

tine at line 32566 to scan the line for instructions that 
might reference line numbers. On return from the subrou¬ 
tine, increment the pointer (P) to the beginning of the 
current line of BASIC by adding the line length (LNTH) to 
it. Then repeat the process, scanning the next successive 
line. 

Lines 32561 - 32571: 

Get the current instruction address (INSADD) from the 4th 
byte of the line currently being scanned. Get the length 
of the current line (LL) from the 3rd byte of the line 
currently being scanned. Using the instruction address 

(INSADD), get the length (IL) of the instruction about to 

be scanned. From the 2nd byte of the instruction, get the 

tokenized instruction code (OP) and the byte following it 

m. 



Program Narrative 
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Lines 32572 - 32581: 

Examine the tokenized instruction code (OP) and the byte 
following it (F) to determine if the combination indicates 
that it is an instruction that could contain a reference to 
a line number. If it is, execute one of the subroutines to 
examine the operands of the instruction to see if they are 
explicit line numbers or variables. 

Lines 32582 - 32590: 

If the tokenized instruction code (OP) was a "7 M , this is 
an IF statement. This subroutine will scan the IF statement 
to see if it contains any implied or explicit GOTOs. 

Lines 32591 - 32605: 

If the tokenized instruction code (OP) was a "30" or a "4", 
this is an ON or LIST statement. Scan it for line number 
operands. 

Lines 32606 - 32619: 

This is the beginning of the subroutine that enters the 
referenced line numbers which were found embedded in the 
BASIC statement, together with the RAM address of each ref¬ 
erence, into the table of references (OLDNR/RAMADD). Upon 
entry, REFADD points to the address within the BASIC line 
of the tokenized reference. Lines 32616 to 32619 break the 
tokenized line number down into 4 discrete bytes (BY1, BY2, 
BY3, and BY4). 

Line 32620: 

Once the line number reference address has been established, 
execute the subroutine at line 32649, which will attempt to 
convert the tokenized line number to a decimal value. 

Lines 32621 - 32638: 

On returning from the tokenized to decimal conversion sub¬ 
routine, the variable OPRND should contain the decimal value 
of the referenced line number. However, if the result of 
the conversion attempt (OPRND) is equal to zero, this indi¬ 
cates that a variable was encountered. In this case, the 
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line containing the variable reference is displayed on the 
screen and the operator asked if he would like to continue, 
or terminate the program. The cursor is restored by POKE- 
ing 0 into location 752, and the operator is prompted for a 
reply (YORN$). The only valid response for continuation is 
an upper-case "Y". If the operator elects to continue 
(YORN$="Y"), the displayed line and the prompt and its re¬ 
sponse are erased from the screen by 8 repetitions of PRINT 
"Shift/Delete", and the program continues. 

Lines 32639 - 32648: 

If the tokenized to decimal conversion subroutine returned 
a valid decimalized line number (OPRND), increment the var¬ 
iable REFCNT, which indicates the number of line number 
references detected so far. This is compared against our 
calculated capacity (CAP), which depended on the amount of 
free RAM available. If REFCNT exceeds our capacity, the 
operator is notified and the process is terminated. Other¬ 
wise, the line number referenced, together with the actual 
RAM address of its tokenized occurrence, are added to the 
table of references (OLDNR/RAMADD). 

Lines 32649 - 32661: 

These lines constitute the subroutine that does the conver¬ 
sion of a tokenized line number to a decimal value in vari¬ 
able OPRND. 

Lines 32662 - 32682: 

This is a subroutine that converts a decimal line number to 
its tokenized form, the result being a four element array 
TL. 


Lines 32683 - 32696: 

Upon completing the scan of the BASIC program, having loaded 
the table of references and their addresses, we come to line 
32692. At this point, execute the subroutine at 32725, 
which will sort the table by line number, to expedite sub¬ 
sequent searching of the table. SRST is initialized to 1, 
to cause our searching to begin, initially, at the beginning 
of the table. SRST will be incremented each time we find a 
line number referenced in the table, thereby decreasing the 
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time required for subsequent searches of the table. Set the 
screen position, display an indication that we have entered 
the actual renumbering process, and set P to once again 
point to the beginning of the BASIC program. 

Lines 32697 - 32713: 

Once more, obtain the original line number (LNMBR) from the 
first 2 bytes of the line, and the length of the line (LL) 
from the 3rd byte. Using the new starting line number 
(NEWNR) as our starting value, develop a new line number. 
Then proceed to search the table, to see if the current line 
number was referenced anywhere. If it was, execute the 
subroutine at line 32753, which will tokenize the new line 
number (NEWNR) and POKE it into the RAM address which was 
obtained from the table. Then POKE the new line number into 
the first 2 bytes of the line itself, and then repeat the 
process for the next line of the BASIC program. 


Lines 32714 - 32720: 

Upon successful completion of the renumbering, the cursor 
display is once again enabled and a tone generated to signal 
completion. A CLR is used to purge RAM of the no longer 
needed arrays, and the BURP ENDS. 


Lines 32721 - 32747: 

This is the subroutine that sorts the table of line number 
references and their corresponding RAM addresses. It is a 
simple version of a "bubble" sort. The number of references 
is displayed, followed by a blinking asterisk, for the pur¬ 
pose of reassuring you that something productive is happen¬ 
ing, and to give some indication of BURP's progress. 

Lines 32749 - 32761: 


This subroutine POKES the new line numbers into the RAM 
locations where they are referenced. Before doing so, how¬ 
ever, they must be tokenized by executing the subroutine at 
line 32666. On return from this subroutine, the four ele¬ 
ment array TL contains the tokenized equivalent of the new 

line number. 
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The variable names used in the unmashed version of BURP 
were chosen to be somewhat descriptive of their function. 
However, in order to minimize the time required to ENTER 
the BURP program in its operational or "mashed £o E“» 
short, non-descript variable names were substituted. ihe 
reason for this should be apparent when you consider that, 
in order to merge it with your BASIC program in RAM, using 
the ENTER statement, BURP must be maintained in untoken- 
ized form on a tape cassette or diskette. The shorter the 
variable names, the fewer bytes must be read from the 
cassette or diskette. Additionally, more statements could 
be "mashed" into one line if the variable names are short. 


Consequently, the "mashed" version of BURP, which is the 
one you should use, was translated to abbreviated variable 
names. The following "dictionaries" are presented to give 
not only an indication of the use of each variable, but 
also to provide a cross-reference of the variable names 
used in each version. You will notice that, in the mashed 
version, some variables are used for several different 
purposes, in order to conserve variable names. 
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(Sequenced by Unmashed Variable Name) 


Mashed 

Unmashed 

Use 

B2- 4 

BI2-4 

Integer value of BY2-4/16. 

Yl-4 

BY1-4 

Breakdown of 4 elements of a tokenized 
line number. 

G 

CAP 

Capacity of the OLDNR/RAMADD tables. 

E 

D 

FOR loop control in sorting routine. 

F 

F 

The byte following the instruction 
code in a line. Also used as a temp¬ 
orary holding area for RAMADD during 
sorting. 

R 

IL 

Length of the instruction currently 
being scanned. 

B 

INCREMENT 

New line number increment value. 

N 

INSADD 

Address of instruction currently being 
scanned. 

X 

J 

Controls FOR loops. 

U 

LH 

Used as work area in tokenizing deci¬ 
mal line numbers. 

Q 

LL 

Line length. 

L 

LNMBR 

Number of line currently being oper¬ 
ated upon. 

M 

LNTH 

Length of line currently being oper¬ 
ated upon. 

V 

LT 

Used as work area in tokenizing deci¬ 
mal line numbers. 

E 

MAXTST 

Variable used to control protection 
against new line numbers greater than 
32499. 

A 

NEWNR 

New starting line number, subsequently 
incremented. 

H 

OLDNR 

Table (array) of old line numbers 
referenced. 
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(Continued.) 

(Sequenced by Unmashed Variable Name) 


Mashed 

Unmashed 

Use 

S 

OP 

Tokenized instruction code of the in¬ 
struction currently being scanned. 

Z 

OPRND 

Referenced line number converted to 
decimal value. 

P 

P 

Current position in RAM being operated 
upon. 

T 

PTR 

Controls FOR loops in scanning lines. 

K 

RAMADD 

Table (array) of RAM addresses of line 
number references. 

U 

REFADD 

Address of a line number reference 
within a line. 

AA 

REFCNT 

Number of line number references de¬ 
tected. 

SR 

SR ST 

Points to position in the table to 
begin a search. 

C 

TL 

Used to create 4-element tokenized 
line numbers. 

D$ 

YORN$ 

Used to INPUT response to yes/no 
queries. 
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(Sequenced by Mashed Variable Name) 


Mashed 

Unmashed 

Use 

A 

NEWNR 

New starting line number, subsequently 
incremented. 

AA 

REFCNT 

Number of line number references de¬ 
tected. 

B 

INCREMENT 

New line number increment value. 

B2- 4 

BI2-4 

Integer value of BY2-4/16. 

C 

TL 

Used to create 4-element tokenized 
line numbers. 

D$ 

YORN$ 

Used to INPUT response to yes/no 
queries. 

E 

D 

FOR loop control in sorting routine. 

E 

MAXTST 

Variable used to control protection 
against new line numbers greater than 
32499. 

F 

F 

The byte following the instruction 
code in a line. Also used as a temp¬ 
orary holding area for RAMADD during 
sorting. 

G 

CAP 

Capacity of the OLDNR/RAMADD tables. 

H 

OLDNR 

Table (array) of old line numbers 
referenced. 

K 

RAMADD 

Table (array) of RAM addresses of line 
number references. 

L 

LNMBR 

Number of line currently being oper¬ 
ated upon. 

M 

LNTH 

Length of line currently being oper¬ 
ated upon. 
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(Continued.) 

(Sequenced by Mashed Variable Name) 


Mashed 

Unmashed 

Use 

N 

INSADD 

Address of instruction currently being 
scanned. 

P 

P 

Current position in RAM being operated 
upon. 

Q 

LL 

Line length. 

R 

IL 

Length of the instruction currently 
being scanned. 

S 

OP 

Tokenized instruction code of the in¬ 
struction currently being scanned. 

SR 

SRST 

Points to position in the table to 
begin a search. 

T 

PTR 

Controls FOR loops in scanning lines. 

U 

LH 

Used as work area in tokenizing deci¬ 
mal line numbers. 

U 

REFADD 

Address of a line number reference 
within a line. 

V 

LT 

Used as work area in tokenizing deci¬ 
mal line numbers. 

X 

J 

Controls FOR loops. 

Yl-4 

BY1-4 

Breakdown of 4 elements of a tokenized 
line number. 

Z 

OPRND 

Referenced line number converted to 
decimal value. 




BURP Constants 


Page 24 


Numeric constants are values expressed by a number (1,024 
for instance) rather than represented by a variable name 
(OLDNR for instance) 


The unmashed version of BURP uses numeric constants in 
some of the calculations because they are "constant" val¬ 
ues, and their numeric representation more clearly indi¬ 
cates the nature of the calculation being performed. 


However, in a tokenized BASIC statement, constants occupy 
more bytes than a variable reference. Therefore, in order 
to reduce the RAM requirement of the "mashed" version of 
BURP, some of these constant values were replaced by var¬ 
iables. The use of these variables, initialized to the 
required constant value, reduce the size of BURP. 

The variables and their equivalent numeric constant values 
are as follows: 

Constant 
Value 


1 

2 

16 

10 

100 

1000 


Variable Equivalent 
Used in Mashed BURP 

W 

W2 

FF 

FG 

FH 

FI 
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With the benefit of hindsight, the author sees several 
opportunities for improving BURP, some of which would in¬ 
crease its RAM requirement, and others which would have 
as their objective the reduction of its size. 

When BURP realizes that it has insufficient RAM to hold 
all of the line number references, it informs you of that 
fact and quits. You might try to beat me to modifying 
that piece of the program so that, rather than abruptly 
quitting, BURP will continue to scan the program to its 
end. Having set a switch when the capacity limit was de¬ 
tected, it could then terminate - but first display the 
total reference count as compared to the array capacity 
available. In this way, you would have some idea of the 
extent to which you exceeded the array capacity. If you 
missed by only a couple of bytes of RAM (each line number 
reference requires 12 bytes of array space), you could 
perhaps temporarily delete a REM statement or two from 
your BASIC program, do your renumber, and then replace the 
REM statements. 

One of these days, when the author can afford an Atari 810 
Disk Drive, he’d like to break BURP up into three or more 
segments. Each would perform one of the basic phases of 
the process and, upon concluding its task, bring the next 
phase segment into RAM on top of itself. This could sig¬ 
nificantly reduce the space requirements of BURP. Maybe 
you'd like to try it yourself. 

BURP was written without access to any documentation 
whatsoever of the internals of the BASIC interpretation 
and tokenizing scheme. I discerned the tokenized instruc¬ 
tion codes and line number representation by typing in a 
BASIC statement and then PEEKing at the tokenized line. 
If you can come up with a more efficient routine for doing 
the conversion from a decimal value to a tokenized line 
number, and vice versa, I'd like to see it, as my manipu¬ 
lations seem to me to be rather cumbersome. 

You might like to make BURP a little more entertaining to 
run by zipping it up with various pleasant (please, noth¬ 
ing obnoxious) sounds that would give you an indication 
of its progress without having to look at the screen. 
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Further Optimization of BURP 
(Continued.) 


The foregoing was primarily for those of you who've got 
RAM to spare. A deliberate effort was made, however, to 
provide a renumbering utility that was usable by those 
people who haven't got a full house. If you're among that 
group, you'll likely be looking to further "mash" BURP, 
sacrificing cosmetic effects for raw function. 

For those of you who would like to squeeze BURP further, 
you might want to consider: 

- Removing the display of information that 
lets you know what BURP is doing. 

- Remove the TRAP on INPUT at the beginning 
of the program. If the user INPUTS a 
non-numeric value when you're prompted 
for the new starting line number or in¬ 
crement, you could just let BURP abort 
itself. No harm will be done. 

- Remove the test for new line numbers 
greater than 32499. You would then have 
to rely on your own mental arithmetic to 
insure that you don't violate this rule. 

Otherwise BURP will, in effect, commit 
suicide by attempting to renumber itself. 

- In preparing these notes, I've noticed 
that I may have overlooked opportunities 
to use a variable for multiple purposes. 

You may want to contemplate doing this 
for the few bytes it will yield. 

Finally, if you really want to make BURP go as fast as 
possible, and don't care to see what's happening, you can 
try disabling Direct Memory Access (DMA) by POKEing zero 
into location 559. There were a couple of magazine arti¬ 
cles published which pointed out that this could yield 
significant processor performance improvements. I won't 
go into detail on this. However, you should know that the 
6502 processor has cycles "stolen" from it by one of the 
outboard chips for the simple task of maintaining the im¬ 
age on your TV screen. Suppressing this chip's access to 
RAM suppresses the TV image, as well as any other I/O ac¬ 
tivity (including keyboard), but lets the 6502 dedicate 
its full resource to the program its running. 
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Further Optimization of BURP 
(Continued.) 


I have not tried it with BURP, but you could disable DMA 
during the lengthy processes - scanning the lines, sorting 
the table, and POKEing the new numbers in - but you would 
have to enable it, by POKEing 34 into location 559, every 
time it was necessary to advise the user of an anomalous 
occurrence, and prompt for his response. 
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As I said earlier, I PEEKed around at a lot of tokenized 
BASIC statements in order to decipher their format and the 
tokenized representations for various operations. 

In some cases, a different decimal token is used to rep¬ 
resent the same operation, depending on whether the oper¬ 
ation is the first on a line of BASIC statements, or is 
embedded within the line. 

For example, in the tokenized line: 

235 GOTO 420 

the GOTO would be tokenized as a decimal 10. 

On the other hand, in the tokenized line: 

235 LET A=B:GOTO 420 

the GOTO would be tokenized as a decimal 23. 


Listed below are the BASIC statements that can or must 
reference line numbers, and the decimal value of the byte 
that BASIC uses to represent their tokenized equivalents. 


Operation 

Token 

LIST 

4 

GOTO 

10 

GO TO 

11 

GO SUB 

12 

TRAP 

13 

RESTORE 

35 

THEN 

27 

ON 

30 


(23 when embedded) 


(24 when embedded) 


(occurs as implied GOTO) 
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(Continued...) 


The process of identifying these tokenized operations is 
not, however, all that simple. For example, a decimal 4 
is also used to represent an OPEN. The LIST operation may 
or may not reference line numbers and may have a device 
code operand. References to line numbers are optional in 
the RESTORE operation. IF statements, tokenized as a 
decimal 7, must be scanned for the possibility of implied 
as well as explicit GOTO’s. 


References to variables are tokenized as a decimal value 
equal to the number of the variable with respect to its 
position in the variable table + 128. 


I will make no attempt at explaining the scheme of token- 
izing numeric constants and references to line numbers. 
While it seems terribly wasteful of space, the authors of 
Atari BASIC undoubtedly did it this way for good reason. 
In any event, it requires 7 bytes of memory, even if the 
value represented is 1. 


Here are some examples of what a tokenized numeric con¬ 
stant will look like: 


50 = 14,64,80,0,0,0,0 
504 = 14,65,5,4,0,0,0 
1800 = 14,65,24,0,0,0,0 
9999 = 14,65,153,153,0,0,0 
32012 = 14,66,3,32,18,0,0 

In each case, the 14 indicates to the BASIC interpreter 
that a constant follows. The examples I have shown all 
fall within the range of allowable line numbers. Numeric 
constants can, however, exceed the maximum value of 32767 
permitted for line numbers. But, in every case where the 
tokenized value represents a line number, the last two 
bytes are always a null (0) value. 
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I hope you find BURP to be worthwhile, not only for the 
function it provides, but as an interesting excercise in 
increasing your understanding, appreciation, and enthus¬ 
iasm for personal computing. 

If you have any problems with BURP, or discover better 
methods of performing some of the functions, I invite you 
to write to me at the address below. 

Happy computing! 


Gifford 0. Kucsma 
R. D. 1, Prescott Circle 
Lebanon, New Jersey 
08833 



125 0 0 REM-B*U*R*P 

3250:1. REM 

32502 REM 

32503 REM 
3250* REM 

32505 REM 

32506 REM 

32507 REM 

32508 REM 

32509 CLR 

32510 PRINT "V 

32511 PRINT "New 

32512 TRAP 32510 

32513 INPUT NEWNR 


—<Rel* 1* 1 > ■ 


BASIC Utility 
f or Renumber ing Pr ograns 


- Dy Q* 0* Kucsna- 

Clear all free RAM* Then 
get the new starting line 
n u fiber an ci the incr e m ent * 


s t a r t 1 i n e ri u m b e r 


3251* PRINT 

32515 PRINT "Increment": 

32516 INPUT INCREMENT 

32517 TRAP *0000 

32518 PRINT 

32519 REM - 

32520 REM Suppress the cursor* 

32521 REM DIMension the variables* 


32522 REM 

32523 POKE 752,1 
3252* DIM TL(*) 
32525 DIM YGRN*<1> 


32526 

32527 

32528 

32529 

32530 

32531 

32532 

32533 
3253* 

32535 

32536 

32537 

32538 

32539 
325*0 
325*1 
325*2 
325*3 
325** 
325*5 
325*6 
325*7 
325*8 
325*9 
32550 

3255 J 

32552 

32553 
3255* 

32555 

32556 

32557 

32558 

32559 

3256 0 
32561 


REM- 

REM Initialize control of Maxi- 
REM mum allowable line #♦ then 
REM calculate the available RAM 
REM and dimension the reference 
REM number table to use it all* 
REM 

LET MAXTST-NEWNR 

LET CAP = INT((FRE(0)-90)/12) 

DIM OLDNR(CAP >* RAMADD(CAP) 

REM- 

REM Main Loop* Scan the pro- 
REM gram, line by line* 

REM 

POSITION 2,5 

P RIN T " S c a n n i n g 1 i n e ♦ " 1 

LET P = PEEK<136 > +PEEK<137)*256 

LET LNMBR-PEEK<P > +PEEK<P + l)*256 

LET LNTH-PEEK ( P+2) 

IF LNMBRC3250 0 THEN GOTO 325*8 
PRINT 

GOTO 32692 

LET MAXTST-MAXTST^INCREMENT 
IF MAXTST<325 0 0 THEN GOTO 32556 
PRINT 
PRINT 

PRINT "New line number exceeds" 
PRINT "the ma >t :i.mum a 11 owable" 
PRINT "value*>" 

POKE 752,0 JGOTO 32631 

POSITION 17*5 

PRINT LNMBR l 

GOSIJB 32566 

LET P=P+LNTH 

GOTO 325*3 

REM - 








3 2 5 6 2 R E ii S u b r o u t i n e t o s e a ri 1 i n e for 
32563 REH operat:ions with 1 ine riumber 
3 Z 5 6 4 R E ri o p e r a n d % ♦ 

32565 REM 

3 25 66 L E T X N S A D D — P + 3 
32567 LET CUMLENTH*Q 
32563 LET LL*PEEK<P+2> 

32569 LET IL-PEEK <INSADD) 

32570 LET OP*PEEK<INSADD+1> 

32571 LET F-PEEK <INSADD+2) 

32572 IF ( < 0P=4) AND < (FO2 0) AND <F<>22))> THEN GO SUB 32595: GOTO 32579 

32573 IF OP-7 THEN GGSUB 32585;GOTO 32579 

32574 IF OP-3 0 THEN GOSLJB 32595: GOTO 32579 

32575 IF ( OP>9 ) AND < OP< 14 ) THEN GOSLJB 32614: GOTO 32579 

32576 IF OP-23 AND F = 28 THEN 32579 

32577 IF (OP-23) OR <QP*24> OR (OP-27) THEN GOSLJB 32614tGOTO 32579 

32578 IF (OP-35) AND (F<>22) THEN GOSLJB 32614 

32579 LET IN5ADD*P+IL 

32580 IF INSADD-P+LL THEN RETURN 
32531 GOTO 32569 

32582 REM - 

32583 REM Scan 'IF' statements* 

32584 REM 

32585 FOR PTR*INSADD+3 TO (P+ID-l 

32586 IF PEEK(PTR)-14 THEN GOTO 32589 

32587 NEXT PTR 

32588 RETURN 

32589 IF <PEEK<PTR-1)*10) OR <PEEK(PTR-1>*27) THEN REFADD*PTR+1:GOSLJB 32616 

32590 GOTO 32587 

32591 REM - 

32592 REM Scan 'ON' and 'LIST' state- 

32593 REM merits* 

32594 REM 

32595 LET 5P*3 

32596 IF OP=4 THEN LET SP*1 

32597 FOR PTR=INSADD+SP TO (P+ID-l 

32598 IF <PEEK(PTR)-4 OR PEEK ( PTR ) =23 OR PEEK < PTR)-24 OR PEEK < PTR ) =18 ) AND PEEK< 
PTR+1) = 14 THEN GOTO 32602 

32599 IF (PEEK<PTR)=4 OR PEEK(PTR)=23 OR PEEK(PTR)=24 OR PEEK(PTR)-18) AND PEEK( 
PTR+1)>127 THEN GOSUB 32622 

326 0 0 
32 6 0 1 
326 0 2 
326 0 3 
3260 4 
32605 
3 2 6 0 6 
32607 
326 0 8 

32609 

32610 
3 2 611 

32612 

32613 

32614 

32615 
3 2 6.1 6 
3 2 617 

32618 

32619 
3 2 6 2 0 
32*21 
3262 2 
32623 
32 6 2 4 
3 o 5 


NEXT PTR 
RETURN 

LET REFADD*PTR+2 
GOSLJB 32616 
LET PTR-PTR+7 
GOTO 32600 

REM- 

REM Set pointers to operand* 
REM go convert to decimal* 

REM a ri d i f no t a 1 i n e nu mber * 
R E ri s h o w t h e 1 i n e * pause* a ri d 
REi v i give operator option of 
REM terminating the program* 
REM 

LET REFADD*INS A D D+3 
REM 

LET BY 1*PEEK(REFADD) 

LET BY2-PEEK(REFADD+1) 

LET BY3-PEEK(REFADD+2) 

LET BY4-PEEK(REFADD+3) 

GOSUB 32649 

IF OPRNDOO THEN GOTO 32639 
PRINT 

LIST LNMBR 
PRINT 

PRINT "Variable reference*)" 










32626 PRINT 

32627 PRINT "Go ahead anyhow"* 

32628 POKE 752,0 

32629 INPUT YGRN* 

32630 IF YORN*<1,1>="Y" THEN 32633 

32631 CLR 

32632 END 

32633 POKE 752,1 

32634 POSITION 2,7 

32635 FOR X = 1 TO 8 

32636 PRINT ""$ 

32637 NEXT X 

32638 GOTO 32648 

32639 LET REFCNT=REFCNT+1 

3264 0 IF REFCNTOCAP THEN GOTO 32646 

32641 PRINT 

32642 PRINT "Insufficient RAM to" 

32643 PRINT "handle More than "JCAP 

32644 PRINT "references*>" 

32645 POKE 752,0:GOTO 32631 

32646 LET RAMADD < REFCNT)-REFADD 

32647 LET OLDNR<REFCNT)=OPRND 

32648 RETURN 

32649 REM - 


32650 REM Subroutine to convert 

32651 REM tokenized line number to 

32652 REM deciMal♦ 

32653 REM 

32654 LET BI2=INT<BY2/16> 

32655 LET BI3=INT(BY3/16) 

32656 LET BI4=INT<BY4/16> 

32657 LET QPRND=0 

32658 IF BY1-64 THEN QPRND*<BI2*10)+<BY2-<BI2*16>> 

32659 IF BY1=65 THEN OPRND=<BI2*10Q0)+<<BY2-<BI2*16X>*100>+<BI3*10>+<BY3-<BI3*lA 
) ) 

32660 IF BY 1=66 THEN OPRND= < BY2*:L 0 0 0 0 > + < BI3*i 0 0 0 > + ( (BY3-(BI3* 16 ) ) *1 0 0 ) + ( BI4*1 0 > + 
<BY4-<BI4)*16> 


32661 

32662 

32663 

32664 
3 2 6 cy 5 
3 2 6 6 6 
3 2 667 

3266 8 
32669 

3267 0 

32671 

32672 


32673 

LET 

32674 

LET 

32675 

LET 

32676 

LET 

3 2 6 7 7 

LET 

32 678 

LET 

32679 

LET 

32680 

LET 

32681 

LET 

3 2 6 8 2 

LET 

32683 

REM 

32684 

REM 

32685 

REM 

3 2 6 8 6 

R E M 

32637 

REM 

3 2 6 8 8 

REM 

32689 

R E M 


RETURN 

REM- 

REM Subroutine to tokenize a 
REM decimal line nunber* 

REM 

FOR J=:L TO 4 
LET TL(J) = 0 
NEXT J 

IF NEWNR>99 THEN GOTO 32672 
LET TL(1)=64 

LET TL < 2) = <<INT(NEWNR/10)>*16)+(NEWNR-<INT(NEWNR/10)*10))tRETURN 
IF NEWNR>9999 THEN GOTO 32677 
TL (1)=65 

TL < 2 ) = (INT < NEWNR/1 000 ) *16) +INT < < NEWNR-< <INT<NEWNR/1000) ) * 1 0 0 0 ) )/l 0 0 ) 
LH=NEWNR~INTCINT<NEWNR/10 0 )*10 0 ) 

TL(3)«<INT<LH/10>*16>+INT<LH-<INT<LH/10>)*10>5 RETURN 
TL(1)=66 

TL(2)=IN T<NEWNR/10 0 0 0 ) 

LT=NEWNR-INT(INT(NEWNR/10 000 )*10 0 0 0 ) 

TL <3) = <INT<LT/10 0 0 )*16 > +INT(< LT-((INT <LT/1000)>*1000>)/100) 
LH«LT-INT<INT<LT/100)*10G > 

TL < 4) = <INT(LH/10 > *16>+INT< LH-<INT(LH/10))*10 > l RETURN 


Go sort the table of refer- 
e n c e % , t h e n r e n u m b e r t h e 
1 i n e 'a , J. o o k i r« 9, u p old 1 i n e s 
i ri t h e t a h 1 e a r» d p o k i n 9 n e w 
t o kenized 1 i rie nufiber i ri t o 
F\' A M 1 o c a t i o n w h e r e 






3269 0 R E M r e f 0 r e ri c e d ♦ 

32691 REM 

32692 GOSUB 32725 

32693 LET SRST=1 

32694 POSITION 2,9 

3 2 6 9 5 P RIN T 1 ' R 0 ri u m b 0 r :i. ng '' J 

32696 LET P-PEEK<136> +PEEK<137)*256 

32697 LET LNMBR=PEEK<P)+PEEK<P+1)*256 

32698 LET LL*PEEK<P+2> 

32699 IF L.NMBR>3249? THEN GOTO 3271*1 

32700 POSITION 14,9 

32701 PRINT LNMBRJ" as "JNEWNR 

32702 IF SRST>REFCNT THEN GOTO 32709 

32703 FOR I=SRST TO REFCNT 

327 0 4 IF LNMBROOLDNR (I) THEN 327 0 7 

32705 GOSUB 32753 

32706 GOTO 32708 

32707 IF LNMBR<OLDNR(I) THEN 32709 

32708 NEXT I 

32709 POKE P+1,INT<NEWNR/256) 

32710 POKE P,NEWNR-<(INT<NEWNR/256))*256) 

32711 LET NEWNR-NEWNR+INCREMENT 

32712 LET P»P+LL 

32713 GOTO 32697 

32714 POKE 752,0 

32715 SOUND 0,40,10,10 

32716 FOR D=1 TO 30 

32717 NEXT D 

32718 SOUND 0,0,0,0 

32719 CLR 

32720 END 

32721 REM - 

32722 REM Subroutine to sort the 

32723 REM re f 0 r 0 nce 1 3 b1 0 ♦ 

32724 REM 

32725 POKE 77,0 

32727 PRINT 

32728 PRINT "Sorting the references*" 

32729 IF REFCNT-0 THEN 32746 
3273 0 FOR D=:L TO REFCNT-1 

32731 POSITION 26,7 

32732 PRINT DJ M "; 

32733 IF OLDNR < D ) OQLDNR < D + i > THEN 32745 

32734 FOR J«D TO 1 STEP -1 

32735 PRINT ,, * M ; 

32736 IF OLDNR(J)<«QLDNR<J+l) THEN 32745 

32737 LET T-OLDNR(J) 

32738 LET F=RAMADD(J> 

32739 LET OLDNR(J>=OLDNR(J+1> 

32740 LET RAMADD(J)=RAMADD(J+1) 

32741 LET OLDNR(J+1)=T 

32742 LET RAMADD<J+l>*F 

32743 PRINT " " ; 

32744 NEXT J 

32745 NEXT D 

32746 RETURN 

32747 REM 

32748 RETURN 

32749 REM - 

3275 0 R t:. M S u b r o u t i n 0 t o p o k 0 ri e w 1 i n 0 
3 2751 R E M n u n b 0 r s i n t o R A M * 

32752 REM 

32753 GOSUB 32666 

32754 FOR J~0 TO 3 

32755 POKE RAMADD(I>+J,TL<J+1> 

32756 NEXT J 
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LET SRST-SRST+1 

RETURN 

REM 

REM- 





DISCLAIMER OF WARRANTY AND LIABILITY ON COMPUTER PROGRAMS 


Neither Atari, Inc* ("ATARI”), nor its software supplier, distributor, or dealers 
make any express or implied warranty of any kind with respect to this computer 
software program and/or material, including, but not limited to warranties of 
merchantability and fitness for a particular purpose* This computer program software 
and/or material is distributed solely on an "as is" basis* The entire risk as to the 
quality and performance of such programs is with the purchaser* Purchaser accepts 
and uses this computer program software and/or material upon his/her own inspection 
of the computer software program and/or material, without reliance upon any 
representation or description concerning the computer program software and/or 
material* Should the computer program software and/or material prove defective, 
purchaser and not ATARI, its software supplier, distributor, or dealer, assumes the 
entire cost of all necessary servicing, repair, or correction, and any incidental 
damages* 

In no event shall ATARI, or its software supplier, distributor, or dealer be liable 
or responsible to a purchaser, customer, or any other person or entity with respect 
to any liability, loss, incidental or consequential damage caused or alleged to be 
caused, directly or indirectly, by the computer program software and/or material, 
whether defective or otherwise, even if they have been advised of the possibility of 
such liability, loss, or damage* 


LIMITED WARRANTIES ON MEDIA AND HARDWARE ACCESSORIES 

ATARI warrants to the original consumer purchaser that the media on which the 
computer software program and/or material is recorded, including computer program 
cassettes or diskettes, and all hardware accessories are free from defects in 
materials or workmanship for a period of 30 days from the date of purchase* If a 
defect covered by this limited warranty is discovered during this 30-day warranty 
period, ATARI will repair or replace the media or hardware accessories, at ATARI'S 
option, provided the media or hardware accessaries and proof of date of purchase are 
delivered or mailed, postage prepaid, to the ATARI Program Exchange* 

This warranty shall not apply if the media or hardware accessories (1) have been 
misused or show signs of excessive wear, (2) have been damaged by playback equipment 
or by being used with any products not supplied by ATARI, or (3) if the purchaser 
causes or permits the media or hardware accessories to be serviced or modified by 
anyone other than an authorized ATARI Service Center* Any applicable implied 
warranties on media or hardware accessories, including warranties of merchantability 
and fitness, are hereby limited to 30 days from the date of purchase* Consequential 
or incidental damages resulting from a breach of any applicable express or implied 
warranties on media or hardware accessories are hereby excluded* Some states do not 
allow limitations on how long an implied warranty lasts, so the above limitation may 
not apply to you* Some states also do not allow the exclusion or limitation of 
incidental or consequential damage, so the above limitation or exclusion may not 
apply to you* 




ATARI PROGRAM EXCHANGE 


REVIEW FORM 


We're interested in your experiences with APX programs and documentation* both favorable and 
unfavorable* Many software authors are willing and eager to improve their programs if they know 
what users want* And, of course* we want to know about any bugs that slipped by us* so that the 
software author can fix them* We also want to know whether our documentation is meeting your needs* 
You are our best source for suggesting improvements! Please help us by taking a moment to fill in 
this review sheet* Fold the sheet in thirds and seal it so that the address on the bottom of the 
back becomes the envelope front* Thank you for helping us! 

1* Name and APX number of program_1_ 

2* If you have problems using the program* please describe them here* 


3* What do you especially like about this program? 


4* What do you think the program's weaknesses are? 


5* How can the catalog description be more accurate and/or comprehensive? 


6* On a scale of 1 to 10* 1 being "poor" and 10 being '‘excellent"* please rate the following 
aspects of this program? 

_Easy to use 

_User-oriented (e*g»* menus* prompts* clear language) 

_Enjoyable 

_Self-instructuve 

_Useful (non-game software) 

_Imaginative graphics and sound 


7* Describe any technical errors you found in the user instructions (please give page numbers)* 




8» What did you especially like about the user instructions? 



9* What revisions or additions would improve these instructions? 



10* On a scale of 1 to 10* 1 representing "poor" and 10 representing “excellent"* how would you 
rate the user instructions and why? 



11* Other comments about the software or user instructions! 



ISTAMF! 


ATARI Program Exchange 
P*0* Box 427 

155 Moffett Park Drive* B-l 
Sunnyvale* CA 94086 


Cseal here] 







